<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: Going from Services to Service Components</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="going_from_services_to_service_components">
<meta name="uma.presentationName" content="Going from Services to Service Components">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="2.4211910729992714E-305"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: Going from Services to Service Components</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">In this guideline, we describe the relationship between service model and design model, in particular the service component elements within the design model. Some service component patterns are also presented.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../rup_soa_plugin/workproducts/soa_svce_model_service_1EE4C96C.html" guid="{FF65B0A2-6C53-4F01-9727-AACDB0D542C8}">Service</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><a id="XE_going_from_services_to_service_components__guidelines_for" name="XE_going_from_services_to_service_components__guidelines_for"></a> 
<h3>
    <a id="Introduction" name="Introduction">Introduction</a>
</h3>
<p>
    The purpose of the <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a></i> is primarily to identify services, their
    organization, collaboration, and their detailed and complete specification. The role of implementation is delegated to
    the existing Neusoft Unified Process (RUP) <i><a class="elementLink" href="./../../../rup/workproducts/rup_design_model_2830034D.html" guid="{8CDAEAD4-5E84-4F50-87FD-3240ED047DE7}">设计模型</a></i>, and specifically the <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_svce_component_E259F3CC.html" guid="{447385A0-E565-4C87-A082-402AF21CA088}">Service Component</a></i> model element. In general, the service model is
    realized by a design model. However, it would be possible to generate artifacts directly from the service model where
    simply specifications are required. It may also be useful to create a use-case model from the service model that allows
    for further description of the services before construction. The advantage of these choices is shown below in that
    whichever choice you make, there is a connection between each in terms of traceability from the use-case model to a
    design model and then to implementation.
</p>
<p align="center">
    <img height="181" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-01.gif"     width="373" border="0" />
</p>
<p>
    It is our recommendation that the service model be realized using a design model. This provides the ability for the
    <i><a class="elementLink" href="./../../../rup/roles/rup_designer_BA8DE74E.html" guid="{DB21F5EF-810B-4994-B120-79FA8774FA9D}">设计人员</a></i> and <i><a class="elementLink" href="./../../../rup/roles/rup_implementer_D145E819.html" guid="{75501BAA-0CCE-4852-A7B2-B10CA71C002A}">实现者</a></i> to
    apply patterns to the design model and model additional capabilities and structures before generating implementation
    artifacts.
</p>
<h3>
    <a id="Service_Components" name="Service_Components">Creating Service Component</a>s
</h3>
<p>
    A service model is a design-time artifact. As such, it does not deal directly with the implementation of services.
    However, the actual implementation of a service or set of services is strictly performed by a service component's
    realization of a service specification. The service specification provides the implementation contract; the technology
    or techniques used to implement the service are irrelevant as long as the contract is fulfilled. In the concept <i><a class="elementLink" href="./../../../rup_soa_plugin/guidances/concepts/service-oriented_architecture_8328ABAD.html" guid="8.613638237693525E-307">Service-Oriented Architecture</a></i>, we introduced the following picture demonstrating
    the relationship between the services we identify and the components and objects that provide the implementation of
    these services.
</p>
<p align="center">
    <img height="241" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_soa-01.gif"     width="241" border="0" />
</p>
<p>
    In this way, we can see how the NUP <i><a class="elementLink" href="./../../../rup/workproducts/rup_design_model_2830034D.html" guid="{8CDAEAD4-5E84-4F50-87FD-3240ED047DE7}">设计模型</a></i> can be used to capture the design of the component and
    object layers, with implementation models and artifacts capturing details of the object layer and associated
    implementation and deployment artifacts. Important aspects of the relationship between the <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a></i> and the component design model are that the set of
    service specifications represent contracts that must be fulfilled, operations identified on specifications must be
    implemented as-is, and that consumers of services are using this same model to understand the interface and behavior of
    the services they expect to use. As such, there is a direct and in general a one-to-one relationship between the
    service specification and some implementation artifact that acts as the initial implementation entry point for the
    service.
</p>
<p>
    For example, consider the following diagram of a service provider showing the details of model elements used in its
    definition.
</p>
<p align="center">
    <img height="139" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-02.gif"     width="246" border="0" />
</p>
<p>
    The key to the use of the service component is that it should be directly traceable to the service model. The easiest
    way to accomplish this is to make use of the fact that the service specification element is a UML Interface that can be
    realized by the service component, thus ensuring its conformance to the structural specification. In this way we would
    get the following result:
</p>
<p align="center">
    <img height="74" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-03.gif"     width="406" border="0" />
</p>
<p>
    It is now the responsibility of the component implementer to define a set of components and classes that provide the
    behavior of the resulting component.
</p>
<h3>
    <a id="Service_Component_Design_Patterns" name="Service_Component_Design_Patterns">Service Component Design
    Patterns</a>
</h3>
<p>
    Having said that the service component simply realizes the service specification does not provide the implementer a
    with much assistance in going from a coarse-grained service definition to a set of fine-grained implementation classes
    and artifacts required to provide the behavior of the service. In this regard, it is common to rely on patterns that
    provide structure to the resulting service component, either as a starting framework or specific patterns to address
    particular policy requirements.
</p>
<p>
    Pattern choice, driven by NFR, architecture [more]
</p>
<p>
    Note that the additional stereotypes introduced here are described in the Work Product: <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_svce_component_E259F3CC.html" guid="{447385A0-E565-4C87-A082-402AF21CA088}">Service Component</a></i>.
</p>
<h4>
    Base Service Component Pattern
</h4>
<p>
    In defining the initial structure of a service, the following pattern is provided as a starting point for customization
    and completion.
</p>
<p align="center">
    <img height="106" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-04.gif"     width="578" border="0" />
</p>
<p>
    The elements of the pattern are:
</p>
<ul>
    <li>
        <b>Facade Component</b>; the facade realizes the same interface as the service component itself and provides basic
        capabilities for message validation before passing the request on to the per-operation components for execution. In
        this case we stereotype the component as &lt;&lt;facade&gt;&gt; for clarification.
    </li>
    <li>
        <b>Per-Operation Component</b>; given the granularity of services, it is useful in most cases to have a separate
        component/class for the implementation of each operation provided by the service.
    </li>
</ul>
<p>
    The following demonstrates the composite structure view of this pattern. In this case, the facade is delegated to by
    the service component itself. As such, consumers calling operations on the service component are actually serviced by
    the facade component. Note that it would be possible to use UML 2.0 ports as well to expose the interfaces and make
    this delegation explicit using connectors.
</p>
<p align="center">
    <img height="119" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-05.gif"     width="274" border="0" />
</p>
<h4>
    Single Operation Service Component Pattern
</h4>
<p>
    In some cases where services are identified in the Service Model with multiple operations, it is more appropriate to
    implement the operations individually as stand-alone services separating the logical service and physical service
    views. Such a pattern has advantages in terms of flexibility of sourcing, high availability, versioning, and evolution
    but does lose the notion of an interface to a service as a set of related operations.
</p>
<p>
    Modeling service components according to this pattern has a single &lt;&lt;Service Component&gt;&gt; realizing a single
    interface with a single operation, all named according to common conventions and demonstrated below.
</p>
<p align="center">
    <img height="113" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-12.gif"     width="394" border="0" />
</p>
<p>
    In this case, as we mentioned, there is no direct realization of the original service specification by any one element
    in the pattern above. Therefore, it seems worthwhile to introduce an element in the model that can provide traceability
    back to the service specification. In the example below, we have introduced a component, stereotyped
    &lt;&lt;subsystem&gt;&gt; that is noted as implementing the service specification and also owning the elements
    described above.
</p>
<p align="center">
    <img height="49" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-11.gif"     width="326" border="0" />
</p>
<p>
    This pattern also does not introduce the &lt;&lt;facade&gt;&gt; component because consumers of the services are
    responsible for identifying the services they use.
</p>
<h4>
    Mediated Operation Pattern
</h4>
<p>
    Where there is the possibility that a service consumer's request may be routed to one of a selection of operation
    components for execution, it is possible to extend the pattern with a mediator to route these messages, as shown below.
    Note we stereotype the component/class as &lt;&lt;mediator&gt;&gt; for clarification. The exact mechanism used for
    mediation is undefined. A static set of implementations could be known ahead of time, a registry of some sort could
    also be used to map to the particular implementation based on the consumer, content of the request message, and so
    forth. This pattern is not intended for use with the single-operation pattern shown above.
</p>
<p align="center">
    <img height="144" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-06.gif"     width="390" border="0" />
</p>
<p>
    This also affects the composite structure view of the service component; as shown below, the mediator connection is
    shown from the facade which uses it to direct calls to the operation components.
</p>
<p align="center">
    <img height="177" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-07.gif"     width="285" border="0" />
</p>
<p>
    If a registry, external to the mediator itself, is used, it is not necessarily possible to show static usage
    dependencies from the mediator to the operation components or connectors between parts in the composite structure
    diagram. So, how can we model a dependency from the mediator to the mediated operation components? In the following
    diagram, we have introduced an interface to be implemented by each operation component. We can then model the usage
    from the mediator to the interface, as shown below.
</p>
<p align="center">
    <img height="74" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-09.gif"     width="550" border="0" />
</p>
<p>
    We also change the relationship in the composite structure diagram, including a new part typed by the interface, and
    denote the multiplicity between the mediator and operation components on the connector, as shown below.
</p>
<p align="center">
    <img height="176" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-10.gif"     width="282" border="0" />
</p>
<h4>
    Data Access Components
</h4>
<p>
    Additionally, where service operations share common data requirements, it may be useful to highlight the specific
    components providing data management capabilities to the implementation. Note we stereotype the component/class as
    &lt;&lt;data access&gt;&gt; for clarification.
</p>
<p align="center">
    <img height="106" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_components-08.gif"     width="534" border="0" />
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
